1. Field of the Invention
The present invention relates to a system and a method for modifying firmware, and more specifically, to a system and a method for modifying firmware of an optical storage medium device without requiring a compiling process.
2. Description of the Prior Art
Video compact discs (VCDs) and digital versatile discs (DVDs) are popular storage media nowadays and there are many VCD/DVD players and recorders on the market. Different video players usually comprise on screen display (OSD) systems and setup menu systems. A user may employ the OSD system or the setup menu systems to adjust configurations related to playback quality controls or functions and options of the video player. For example, the user can choose a particular section of the video content stored on the disc for playback by the video player.
Please refer to FIG. 1 showing a functional block diagram of a video player 10 according to the related art. For example, the video player 10 could be a consumer device such as a digital video disc (DVD) player and includes a processor 12 and a memory unit 14. Generally speaking, the memory unit 14 is a read only memory (ROM) and stores a firmware 16, which is an executable file used to store binary code for controlling the operation of the video player 10. Usually the firmware 16 is generated by compiling source code provided by the manufacturer of the video player 10, and the source code is written in a programming language such as the C programming language or another high level programming language that must be compiled to generate binary code. As shown in FIG. 1, the processor 12 is coupled to the memory unit 14 and a display 18 for reading and executing the firmware 16 to thereby control the video player 10. The display 18 can be utilized for displaying a user interface provided according to the firmware 16, or for displaying the contents of an optical disc played by the video player 10.
According to the related art design process, when developing the firmware 16 of the video player 10 (e.g., for providing the OSD system and the setup menu system of the user interface), the manufacturer of the video player 10 must develop a C program (or a program composed of source code according to another programming language) to meet the requirements specified by a customer. The C program must then be compiled to generate an executable file (i.e., the firmware 16). To complete the process, the firmware 16 is stored into the memory unit 14 of the video player 10. When the manufacturer performs a functional test of the firmware 16, according to a typical method, the manufacturer utilizes the processor 12 to execute the firmware 16 so as to control the video player 10. This process allows the manufacturer to verify whether the execution result meets the requirements as specified by the customer.
Please refer to FIG. 2 showing a flowchart describing the steps of generating and modifying firmware according to the related art. As previously mentioned, the manufacturer of the video player 10 conventionally must create a program file, for example, using the C programming language, according to the hardware architecture of the video player 10 and the software requirements specified by the customer (steps 100 and 102). The program file stores the source code of the program and is compiled by a C compiler to obtain the firmware 16 (step 104). Please note that the program file could also contain a program written in another programming language. Conventionally, the firmware 16 cannot be verified to ensure that it meets the design requirements specified by the customer until after the firmware 16 is stored into the memory unit 14 of the video player 10 at step 106. Afterwards, a function verification process can be performed on the hardware platform of the video player 10. In other words, the processor 12 executes the firmware 16 and then performs the function verification process (step 108). When the testing results of the function verification process do not meet the requirements of the customer, the manufacturer must modify the program file according to the testing results to try to meet the requirements (step 112). The program file is then re-compiled to again generate corresponding firmware 16 (step 104), and the above-mentioned function verification process is again executed on the hardware device (the video player 10) to check if the new firmware 16 can enable the video player 10 to execute target operations that meet the requirements specified by the customer.
As shown in FIG. 2, if the customer wants to redesign a function related to the firmware 16 of the video player 10, a large number of tests need to be performed utilizing the hardware (i.e., the video player 10). In addition, step 104 in which the program file is compiled to generate the corresponding firmware 16 is time-consuming, and this results in substantial delays during the product development process. Step 104 is inevitable when a hardware test on the video player 10 is performed because a firmware coding engineer cannot directly modify or edit the firmware 16 without the use of a software package based on the C programming language or a similar high-level programming language. That is, the program file must be compiled so as to generate the modified firmware 16 in order to test each version of the firmware 16 during development. Additionally, the customer may be incapable of editing program files and may instead simply provide their specifications (i.e., the design requirements of the OSD system and the setup menu system) or feedback to the manufacturer of the video player 10 in a written form or during an oral conversation. The firmware coding engineer of the manufacturer must then modify the program file according to the requirements specified by the customer, and the modified program file must be re-compiled to obtain the corresponding modified firmware 16. Afterwards, the function verification process is performed on the hardware platform of the video player 10, and the customer can again give feedback on the test results. The program file may then be modified according to the customer's feedback if necessary, and the above-mentioned compiling step is repeated yet again. Obviously, using the above-mentioned communication process and design flow may be unable to efficiently identify actual customer requirements and may even result in misunderstandings between the developer and the customer. Therefore, significant effort and time may be expended on the resulting modification cycles and various design corrections.